Processors are often configured to support multiple execution modes. For example, a first execution mode may comprise instructions of fixed-width, while a second execution mode may support variable-width instructions. A common address space may be shared between instructions in each mode, such that a same address or program counter (PC) value may point to a first instruction if the processor is in the first execution mode or to a second instruction if the processor is in the second execution mode. Because the processor may be capable of switching between the two modes, it becomes necessary to track the execution mode to ascertain which one of the two instructions is addressed by a current PC value, and thus ensure that instructions are being executed correctly.
With reference to a known ARM processor, an ARM mode supports fixed-width (32-bit) instructions, while a THUMB mode supports variable-width (16-bit and 32-bit) instructions. A common address space in a byte-addressable memory may comprise instructions in both ARM and THUMB modes. However, alignment of instructions in the two modes may be different. For example, ARM mode instructions may be aligned at 32-bit boundaries, such that the two least significant address bits for the ARM mode instruction will always be “00”. On the other hand, THUMB mode instructions may be aligned at either 16-bit or 32-bit boundaries, such that the two least significant address bits for the THUMB mode instructions may be “10” or “00.” Thus, knowing the address alone is insufficient to conclusively determine which one of the two modes, ARM or THUMB, is currently being executed.
In order to track which mode is being executed, ARM processors adopt an approach which includes storing a mode bit in the least significant bit (LSB) of the PC. The LSB of the PC in THUMB mode may be a reserved bit because as noted above the two least significant address bits are either “10” or “00” and thus the LSB (which is “0” in both cases) may be used to store a mode bit. Execution may switch between the ARM mode and the THUMB mode on function calls, such as a jump instruction. Thus, if a jump instruction transfers execution to a function comprising instructions in THUMB mode, then the ARM processor implements this change in modes to THUMB mode by jumping to the address of the function +1. In this manner, the value of the two least significant bits in the THUMB mode are either “11” or “01,” thereby distinguishing them from the “00” value of the two least significant bits in the ARM mode.
While the above approach adopted by ARM processors accomplishes the objective of tracking execution modes, it suffers from corresponding limitations. For example, addition of “1” is required as noted above for every jump to THUMB mode. This complicates the software, and particularly the linker. The linker has to determine the mode of each function and then choose between a regular call and a mode switching call for all calls to each function. Additionally, the debugger is also affected because the debugger would need to keep track of functions being called from within the debugger to determine whether these functions are ARM or THUMB functions in order to determine whether to jump to the PC value of the function or to jump to the PC value of the function +1 respectively.
Yet another drawback associated with the above approach arises from using the LSB of the PC to store the mode bit. Because the LSB is used to represent the mode, the LSB is no longer a part of the actual address. Therefore, if the ARM processor were to include 8-bit and 24-bit instructions to THUMB mode, the starting point of every function in THUMB mode would still be required to be 16-bit aligned in order to facilitate mode tracking. This would entail requiring about half of all the functions to introduce an 8-bit no-operation instruction (nop) before the start of the functions in order to align the first instruction in the function to a 16-bit boundary.
Other known processor architectures, such as MIPS and PowerPC face similar challenges related to switching between execution modes and adopt similarly disadvantaged methods to handle these challenges. Correspondingly, the existing architectures exhibit drawbacks in their approaches to track and switch between execution modes. For example, some approaches involve using the PC value of an instruction stored in an associated memory management unit (MMU) to determine the execution mode for the instruction because any page in the MMU can belong to either mode. A drawback in terms of increased hardware cost of using a page attribute to determine the mode is that the mode bit takes up additional room in the page table entry, of the MMU, and conventional page table entries are constrained in their size. Drawbacks in terms of software costs of using a page attribute to determine the mode include, complicating the loader, which would have to determine which mode a page is supposed to be in and then fill in the appropriate bit in the page table entry for that page. Further, the debugger would have to look up the entry in the page table for a particular page before it can disassemble instructions in that page. Similarly deficient are other known approaches that include specific program code for determining the mode associated with addresses using reserved operation code (OpCode) bits.
Accordingly, there is a corresponding need in the art to overcome drawbacks of aforementioned approaches for tracking and switching between execution modes.